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triebssystem (4) und Anwendersoftware (5) und Mittel 
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wird mit den ubertragenen Zustanden und Nachrichten 
neu gestartet. 
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Beschreibung 

BESCHREIBUNG 

Kommunikationssystem mit Mitteln zum Austausch von Software 

Die Erfindung bezieht sich auf ein Kommunikalionssystem mlt einer Steuerschattung, welche ein Betriebssystem 
und Anwendersottware und Mitte! zum Austausch von Software enthatt. 

Kornmunikationssysteme enthalten Computersysteme oder Steuerschaltungen, deren Software langtebig und 
praktisch dauernd verf ugbar sein soil. Bei Fehlern in der Software oder auch autgrund neuer Anforderungen mussen 
bestimmte Softwarekomponenten erneuert werden. Dabei solttedie Ausfallzeit des Kommunikationssystems minimiert 
werden. 

Ein Kommunikationssystem, welches paktisch keine Ausfatlzeit bei dem Austausch einer Software einer Kompo- 
nente eines Vermittlungssystem aufweist, ist aus der US-A-5 155 837 bekannt. Vor dem Austausch werden zuerst die 
Inhalte und Zustande alter Register Prozesse und Speichereinheiten in einem speziellen Speicher wahrend des Be- 
triebes der atten Software gesichert (Spalte 7. Zeilen 30 bis 36). Die arte Version der Software ist dabei in einer ersten 
Partition geladen. Die neue Software wird anschtieBend in eine zwerle Partition geladen. Nachdem die neue Software 
geladen und getestet worden ist, werden aus dem Speicher die Inhatte und Zustande aller Register, Prozesse und 
Speichereinheiten auf die neue Software ubertragen. Diese wird dann in Betrieb genommen. Die neue Software beginnt 
dabei jedoch nicht an dem ProzeBpunkt zu arbeiten, an dem die alte Software angehaften worden ist, sondem an 
einem definierten Programmpunkt. Es werden auch nicht einzetne Softwaremodule oder -kornponenten, sondem eine 
in sich geschiossene Software ausgetauscht. 

Der Erfindung fiegt daher die Aufgabe zugrunde, Softwarekomponenten auszutauschen, bei welcher auBer einer 
kurzen Verzogerung keine Einschrankung des Betrtebes erfolgt. 

Die Aufgabe wird durch ein Kommunikationssystem der eingangs genannten Art dadurch geldst, 
daB das Betriebssystem zum Austausch von Nachrichten vorgesehen ist und daG eine neue geladene Softwarekom- 
ponente (Nachfolgerkomponente) zum Empfang der Zustande und der Nachrichten von einem Dienst-Port einer an- 
gehaltenen, zu ersetzenden Softwarekomponente (Vorgangerkomponente) und zum Neustart mit den ubertragenen 
Zustanden und Nachrichten vorgesehen ist. 

Die Erfindung ermoglicht den Neustart der neuen Softwarekomponente an dem Programmpunkt, an dem die atte 
Softwarekomponente angehalten worden ist. AuBerdem werden alle Zustande der alten Softwarekomponente zur neu- 
en Softwarekomponente ubertragen. Dies kann aber nur fur solche Systeme gellen, die ein Betriebssystem aufweisen, 
welches den Austausch von Nachrichten zwischen Softwarekomponenten ermoglicht. Hierbei werden Nachrichten 
Ober Softwareschnittstellen, die im folgenden als Ports bezeichnet werden, zwischen verschiedenen Prozessen aus- 
getauscht. ErfindungsgemaB werden also in der atten Softwarekomponente alle Zustande und alle an einem Dienst- 
Port anliegenden Nachrichten eingesammett und zur neuen Softwarekomponente ubertragen. Ober einen Dienst-Port 
empfangt die Softwarekomponente alle Nachrichten von anderen Prozessen. Die neue Softwarekomponente uber- 
nimmt die neuen Zustande. fuhrt gegebenenfatls eine Zustandstransformation durch und startet die neue Software in 
dem Programmpunkt der neuen Softwarekomponente, der dem der alten Softwarekomponente entsprbht. 

Der Austausch einer Softwarekomponente erfolgt dabei so, daB keine andere Softwarekomponente davon beruhrt 
wird. Die von einer anderen Softwarekomponente eintreffenden Nachrichten werden namlich auf die neue Software- 
komponente ubertragen und nach dem Austausch weiterverarbeitet. Der Autausch erfolgt dabei so, daB nur eine kurze 
Verzogerung bei der Bearbertung entsteht. Praktische Untersuchungen haben ergeben, daB die Verzogerungszeit im 
Beretch weniger Mitlisekunden liegt. 

Ein Kommunikationssystem kann ein Computersystem sein, eine Vermittlungsstelle, ein Computemetzwerk oder 
auch Serversysteme, wie z.B. ein Vide-On-Demand-Server. Ein Computerssystem enthatt wenigstens einen Computer, 
in dem eine Softwarekomponente ausgetauscht werden soil. 

Eine Softwarekomponente oder ein ProzeB enthatt genau einen Thread. Ein Thread ist ein in sich sefbst sequential 
ablaufendes Programmstuck. Der Thread weist einen ersten Teil zur Obernahme und geeigneten Umsetzungder Zu- 
stande und Nachrichten des Dienst-Ports einer atten Softwarekomponente und einen zweiten TeH zum Etnsammein 
der Zustande des Prozesses und der Nachrichten des Dienst-Ports auf. 

Der Austausch einer Softwarekomponente wird von einem Austauschmanager gesteuert, welcher zum Laden und 
Starten einer Softwarekomponente vorgesehen ist Die neue Softwarekomponente kann dabei von einer Wartungs- 
vorrichtung an den Austauschmanager geliefert worden sein. an der auch neue Softwarekomponenten entwickelt wer- 
den konnen. Als Ubertragungsmedium kann beispielsweise das Telefonnetz dienen. 

Ausfuhrungsbeispiele der Erfindung werden nachstehend anhand der Figuren naher erlautert. Es zeigen: 

Fig 1 ein Computersystem mit einer Wartungsvorrichtung und einem Computer, der austauschbare Softwarekom- 
ponenten enthatt. 
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Fig. 2 den NachrichtenfluG zwischen dem Austauschmanager, einer neuen und alten Softwarekomponente, 
Fig. 3 ein Vermittlungssystem mit einer Warlungsvorriehtung und einer Steuerschaltung, die austauschbare Sofl- 

warekomponenten enthalt, 
Fig. 4 ein Zustandsdiagramm einer nicht austauschbaren Soltwarekomponente und 
Fig. 5 ein Zustandsdiagramm einer austauschbaren Softwarekomponente. 

In Fig. 1 ist ein Computersystem mit einem Computer 1 und einer Wartungsvorrichtung 2 dargestellt. Der Computer 
enthalt Hardwarekomponenten 3, ein Betriebssystem 4, Anwendersottware 5 und einen Austauschmanager 11. Das 
Betriebssystem 4 muB eine Kommunikation zwischen Softwarekomponenten der Anwendersottware 5 uber Nachrich- 
ten ermoglichen (z.B. nachrichtenorientiertes Betriebssystem (message based operating system)). Die Nachrichten 
Oder Daten werden dabei uber Softwareschnittstellen ausgetauscht. Im folgenden wird eine Softwareschnittstellen als 
Port bezeichnet. 

Der Austauschmanager 11 ist eine Softwareprogramm, mit dessen Hilte Komponenten der Anwendersottware 5 
ausgetauscht werden konnen. In der Fig. 1 sind die einzelnen Softwarekomponenten durch Kreise dargestellt Die 
Verbindungen zwischen den Kreisen sollen Nachrichtenflusse zwischen den Softwarekomponenten andeuten. 

Die Wartungsvorrichtungvorrichtung 2 konnte ein enttemt liegender Computer sein, von dem aus eine neue Soft- 
warekomponente gelietert wird. Hierbei ist es denkbar, da(3 die neue Softwarekomponente an diesem Computer ent- 
wickelt und getestet wird. Zur Ubertragung der neuen Softwarekomponente konnen bekannte Ubertragungsmedien 
und Protokoile verwendet werden. Beispielsweise ist eine Ubertragung uber ein Teletonnetz moglich. Die neue Soft- 
warekomponente konnte aber auch direkt in den Computer 1 geladen werden (z.B. mit Hilfe einer lokalen Wartungs- 
vorrichtung (Laptop)). 

Der Austauschmanager 11 ladt die neue Softwarekomponente in den Computer 1 und startet sie dort. Die neue 
Komponente meldet sich bei dem Austauschmanager 11 an und bekommt mitgeteilt, ob sie eine existierende alte 
Komponente ersetzen soil. Falls das der Fall ist, sendet die neue Komponente, die eine Nachfolgerkomponente dar- 
stellt, einen Austauschbefehl (request) an die alte Komponente, die eine Vorgangerkomponente darstellt. Die Vorgan- 
ger komponente sammelt ihre Zustandsinformationen und ubertragt diesen Zustand zur Nachfolgerkomponente. Au- 
Berdem meldet die Vorgangerkomponente dem Austauschmanager 11 , daB sie gestoppt hat. Danach setzt die Nach- 
folgerkomponente die Arbeit exakt an der Stelle fort, an der die Vorgangerkomponente gestoppt wurde. Damit dieser 
Austausch, ohne daB der Computer auBer Betrieb genommen wird, durchgefuhrt werden kann, sind in den Kompo- 
nenten der Anwendersottware noch bestimmte Veranderungen gegenuber nicht austauschbaren Komponenten vor- 
genommen worden. 

Wie oben erwahnt mOssen die Softwarekomponenten, welche austauschbar sein sollen : gegenuber konventio- 
nellen Softwarekomponenten Erweiterungen besilzen. Eine Softwarekomponente weist genau einen Thread auf, der 
einen Dienst-Port fur den Empfang von Nachrichten (messages) von einem Klienten und einen Teil zur Antwort auf 
die Nachrichten an einen Klienten aufweist. Ein Thread ist ein in sich selbst sequentiell ablaufendes Programmstuck. 
Ein Klient ist eine andere Softwarekomponente (ProzeB). Damit eine Softwarekomponente austauschbar wird, muB 
sie einen Austausch-Punkt bzw. Restart-Punkt im Thread aufweisen. In der Regel sind der Austausch-Punkt und der 
Restart-Pun kt identisch. 

In Fig. 2 ist schematisch der NachrichtenfluB zwischen dem Austauschmanager 11 (hier als AM bezeichnet), der 
Vorgangerkomponente VK und der Nachfolgerkomponente NK dargestellt. Nachdem die neue Komponente NK vom 
Austauschmanager gestartet worden ist (Pfeil ST), werden von dieser bestimmte Informationen geholt (Punkt P1 ). Die 
Vorgangerkomponente VK ermoglicht am Punkt P2 die Erfullung ihrer Aufgaben, d.h. z.B. die Bearbeitung extemer, 
anliegender Nachrichten. Die Nachfolgerkomponente NK meldet sich dann beim Austauschmanager 11 (AM) an (Pfeil 
AN), der anschlieBend der Nachfolgerkomponente NK den Befehl zum Austausch der Komponenten gibt (Pfeil EX1). 
Dieser Befehl wird von der Nachfolgerkomponente NK weiter an die Vorgangerkomponente VK gegeben (Pfeil EX2). 
Daraufhin sammelt die Vorgangerkomponente VK ihren Zustand (Punkt P3) und lietert diesen an die Nachfolgerkom- 
ponente NK (Pfeil ZU). Die Nachfolgerkomponente NK rekonstruiert aus den empfangenen Zustanden die Objekte 
und fOhrt gegebenfalls eine Zustandstransformation durch. AHe Nachrichten die wahrend des Austauschvorgangs fur 
einen Dienst-Port der Vorgangerkomponente VK bestimmt waren, werden dadurch zum Dienst-Port der Nachfolger- 
komponente NK gegeben. AnschlieBend meldet die Vorgangerkomponente VK dem Austauschmanager 1 1 (AM) : daB 
sie gestoppt hat (Pfeil VG) und loscht sich (Punkt P4). Die neue Komponente NK ubemimmt danach die Bearbeitung 
der externe Nachrichten (Punkt P5). 

Der Computer 1 konnte beispielsweise auch ein Server in einem Computernetzwerk sein. Eine weitere Anwen- 
dungsmoglichkeil besteht fur Systeme, welche zur Ubertragung von Nachrichten vorgesehen sind. Ein Beispiel ist ein 
Vermittlungssystem, deren wesentliche Blocke in Fig. 3 gezeigt sind. Das Vermittlungssystem enthalt ein Koppelfeld 
6 welches auf Eingangsleitungen 7 empfangene Signale an eine Oder mehrere Ausgangsleitungen 8 weitergibt. Zur 
Steuerung des Koppetfeldes dient eine Steuerschaltung 9, die auBer den notwendigen Hardwarebestandteilen ein 
Betriebssystem, Anwendersottware und einen Austauschmanager enthalt. Zum Austausch von Komponenten der An- 
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wendersoftware ist eine Wartungsvorrichtung 10 vorgesehen, die mit der Steuerschaltung 9 aul dieselbe Weise wie 
die Wartungsvorrichtung 2 mil dem Computer 1 zusammenarbeitet. 

Anhand eines in der Programmiersprache C++ geschriebenen Prozesses sol! im folgenden etwas detail! ierter der 
Aufbau einer austauschbaren Softwarekomponenle erlautert werden. Zuerst wird der konventionelle Aufbau des Pro- 
zesses ohne die fur den Austausch notwendigen, erfindungsgernaBen MaBnahmen beschrieben. Der ProzeB ermog- 
licht mittels Spracheingaben ein Telefonbuch zu verwatten. Der Teletonbuch-ProzeB stellt anderen Prozessen drei 
Melhoden zur Verfugung. Das ist erstens das Hinzufugen eines Eintrages zum Telefonbuch, zweitens das Loschen 
eines Eint rages aus dem Telefonbuch unddrittens das Ermitteln eines Eintrages aus vorgegebenen Sprachdaten. Ein 
ProzeB liefert dazu dem Telefonbuch-ProzeB eine Nachricht, aus der die entsprechende gewunschte Methode her- 
ausgefunden wird. Die Implementation des Telefonbuch-Prozesses ist im folgenden aufgefuhrt: 



(1) #include "audiodat.hxx" 
#include "bin.hxx* 
^include "port.hxx" 
#include "s.hxx" 
#include "thread, hxx" 

(3) class PhoneBook { 

// ... Hier befinden sich die Defmitionen der 
// internen Datenstrukturen des Telefonbuchs. 
public: 

void enter(S name, unsigned phoneNumber, AudioData reference) { 
// ... Einfugen eines Names mit Telefonnummer 
// und Sprachreferenz in das Telefonbuch 

} 

void remove(S name) { 

// ... Loschen eines durch den Namen 

// referenzierten Eintrages aus dem Telefonbuch 



// Klasse 'AudioData' zur Sprach-Reprasemation 
// Nachrichten-Puffer-Klasse 'Bin' 
// Port-Klasse 'Port' 
// String-Klasse S' 
// Thread-Klasse 'Thread' 
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void give(AudioData reference, S& name, unsigned& phoneNumber) { 
// . . . Finden eines Eintrages im Telefonbuch 
// basierend auf einer Sprachreferenz 

} 

}; 

(8) enum Request { Enter, Remove, Give }; 

(9) Port* phoneBookEntry; // Nachrichtenadresse fur meine Klienten 
PhoneBook* phoneBook; // Reprasentiert das Telefonbuch 

(10) void phoneBookServiceO { 

(13) phoneBookEntry = new Port("phoneBookEntry\ Port:: Overtype); 
phoneBook = new PhoneBook; 

(14) while(l) { 

(15) Bin message; phoneBookEntry- >receive(message); 
int request; 

message > > request; 

// Extrahiert Typ der aufgerufenen Methode aus 
// empfangenen Daten. 

(16) switch(request) { 

case Enter: { 

S name; unsigned phoneNumber; AudioData reference; 
message > > name > > phoneNumber > > reference; 
phoneBook- >enter( name, phoneNumber, reference); 

} 

break; 

case Remove: { 
S name; 

message > > name; 



EP0743 595 A2 



phoneBook- > remove(name); 

} 

5 

break; 
case Give: { 

10 AudioData reference; S name; unsigned phoneNumber; 

message > > reference; 

phoneBook- >give( reference, name. phoneNumber); 
is messagexlear(); 

// Loschen, weil er fur die Ruckantwon gebraucht wird 

message < < name < < phoneNumber; 
20 II Zusammenstellung Ruckantwon 

reply(message); 

} 

break; 

} 

} 



40 



(18) Thread pBS(phoneBookService); 

// Deklariert und startet den Thread des sprachgesteuerten Telefonbuchs. 

Telef«?^f^!r IT'Trf^ ^ " Ur die Deklara ' i0flen a w^he zum Verstandnis des 

erforderl«h s,nd. Das Programm enthaR zur Bezugnahme Abschnittsnummem. welche nicht 
Bestandte,. des Programmtextes sind. Einzelne Programmable werden jeweits durch vorangestelRe in Klam 
mem angegebene Zahten gekennzeichnet. ^ ' ,n * H,n 

buchP^e^fl^ ] ^ fl. ' mPOrte " nd DeWara,ionen vo " •<*»■" ™ Ojeklen en.halten. die im Te.efon- 
buch-ProzeB verwendet werden. In dem Abschnitt (1 ) werden einige Bibliotheken (Headerdateien) in den ProzeO ein- 

•Ent^™^'^ 8 °? rmton einer imemen Tele,0 ^-K^se 'PhoneBook" Die Implementation fur 
N^n h tT! ° "*** m ein2elnen au, 9e«0hrt Die Melhode 'Enter' erlaubt das EinlOgen eines 

Namens mrt Telelonnumme, und Sprachreferenz (Sprachprobe) in das Telefonbuch, die Methode 'Remove' erlaubt 
das Loschen e.nes durch den Namen ref erenzierten Eintrages aus dem Telefonbuch unddie Methode 'Give' ermoglicht 
das F.nden ones Emtrages im Telefonbuch der auf einer Sprachreferenz basiert In diesem Fall sucht jemand also 
Er.rage unter emen Namen, den er sprachlich vorgfct. Die Methoden 'Enter-, -Remove' und 'Give' erhatten und 
ube geben l ewe 1 b d,e .n den Klammem zu den jeweiligen Methoden angegebenen Parameter 
stem .n^Llm^w 11 o Me, ^° den * ™«*«*-P««* anderen Prozessen zur VerfOgung 

Telef^buch erfolgen. Em Port d*nt zu, Versendung von Nachrich.en an andere Prozesse. In Abschnitt (9) wird auch 
wareobjekles bildet. Das Objekt 'PhoneBook' verwattet alle relevanten Daten des Telefonbuchs. 



10 
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In den Abschnitt (10) bis (16) wird die Hauplfunklion des Telefonbuch-Prozesses angegeben. Diese Funktion wird 
als Thread a usgefuhrl. Der Thread besteht aus einen Intialsierungsteil im Abschnitt (13) und einer Endlosschteife (ab 
Abschnitt ( 1 4)). in der Methodenauf rule empfangen werden (Abschnitt (1 5)) und in der die Methodenaulrute ausgef uhrt 
werden (Abschnitt (16)). Im InitiaHsierungsteil im Abschnitt (1 3) wird der Anfangszustand des Softwareobjektesgesetzt. 
In der Schleife, die mit Abschnitt (14) beginnt, wird auf eine Antorderung gewartet. Falls eine Nachricht von dem Dienst- 
Port empfangen worden ist (Abschnitt (15)) wird diese im Purler 'message" abgelegt. Die Nachricht enthalt immer 
zuerst den Typ der aufgerufenen Methode und je nach Methode ncch zusatzliche Parameter. In Abhangigkeit vom Typ 
(Request) wird entweder zur Methode "Enter", zur Methode "Remove" oder zur Methode "Give" gesprungen. Die Me- 
thode "Enter" fugt in das TelefonbuchObjekt "phoneBook" den Namen. die Telefonnummer und eine Sprachreferenz 
ein. Die Methode "Remove" entfernt aus dem Teletonbuch-Objekt "phoneBook" den Namen mit den entsprechenden 
Eintragungen. Fur die Methode "Give" wird z.B. noch eine Sprachreferenz ubermittett, die in eine Variable "reference" 
vom Typ "AudioData" abgelegt wird. Uber einen Autruf der Methode "Give" des intemen Objekts "phoneBook" werden 
dazu ein Nutzername "name" und eine Telefonnummer 'phoneNumber' ermittelt und mittets des Befehls "reply" an 
den Klienten gesendet, der nach der entsprechenden Telefonnummer gefragt hat. In Abschnitt (18) ist eine Deklaration 
'5 auf gef uhrt, durch die der Thread instantiiert, mit der die Funktion "phoneBookService" verbunden und gestartet wird. 
Die Funktion "phoneBookService" beginnt ab Abschnitt (10). 

Der Ablaut des Threads kann durch das in der Fig. 4 dargestellte Zustandsdiagramm noch weiter veranschaulicht 
werden. Block 23 bezeichnet den Zustand (Zustand L, loaded), in den das gesamte Sottwareobjekt von dem Aus- 
tauschmanager 11 in den Arbeitsspetcher des Computers 1 oder der Steuerschaltung 9 geladen wurde. Nach der 
20 Initialisierung tritt der Thread in einen Initialisierungszustand (Zustand I, initialized), was der Block 24 angibt. Der 
nachste Zustand RAC (running application code) zeigt die eigentliche Ausf uhrung des Threads (Block 25) und wird im 
Programm durch die Abschnitte (14) bis (16) beschrieben. Der Zustand RAC weist weitere Unterzustande WFR (Block 
26, waiting for requests), ME (Block 27, processing "enter"), MR (Block 28, processing "remove") und MG (Block 29, 
processing "give") auf. Der Pfeil mit dem Punkt auf der linken Seite des Blockes 26 kennzeichnel den Unterzustand, 
2S der eingenommen wird, wenn das Programm in den ubergeordneten Zustand eintritt. Im konkreten Beispiel heiRt das, 
dafi der Zustand RAC immer mit dem Unterzustand WFR beginnt. Im Zustand WFR wird auf Nachrichten gewartet. 
Nach Eintreffen einer Nachricht wird in einen der Zustande ME, MR oder MG gesprungen. Diese Zustande korrespon- 
dieren mit der Ausf uhrung der Methoden "Enter", "Remove' und "Give" Nach Beenden einer der Methoden wird in 
den Zustand WFR zuruckgesprungen. 
30 Urn den Austausch einer Softwarekomponente durchzuf uhren, ist der oben dargestellte Tetefonbuch-ProzeB durch 

weitere Deklarationen zu erweitem. Diese zusatztichen Abschnitte und die schon oben beschriebenen Abschnitte des 
Telefonbuch-Prozesses sind im folgenden aufgefuhrt: 



40 
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(1) include "audiodai.hxx" // Klasse 'AudioData' zur Sprach- Representation 
5 ^include "bin.hxx" // Nachrichten-Puffer-Klasse 'Bin' 

#include "port.hxx" // Port-Klasse Tort' 

include "s.hxx" // String-KIasse 'S' 

w ^include " thread, hxx" // Thread-Klasse 'Thread' 

(2) include "exchange, hxx" // Definiert 'getExdnfo' und 'setExcInfo' 

is (3) class PhoneBook { 

// ... Die hier deklarierten internen Daienstmkturen 

// des Telefonbuchs sollen verandert werden. 
20 public: 

void enter(S name, unsigned phoneNumber, AudioData reference) { 
// Einfugen eines Names mit Telefonnummer 
// und Sprachreferenz in das Telefonbuch 

} 

void remove(S name) { 

// ... Loschen eines durch den Namen 
// referenzierten Eintrages aus dem Telefonbuch 

} 

void give(AudioData reference, S& name, unsigned* phoneNumber) { 



25 
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// ... Die (hier nicht aufgefuhrte) Implementation 
// dieser Methode ist verbessert worden. 

} 

PhoneBookO {}; // Standardkonstmktor 

(4) PhoneBook(Bin buO { 

// ... Zusatzlich notwendiger Konstruktor zur 

// Erzeugung des Objektes aus einem Pufferabbild. 

} 

(5) static Bin& operator < <(Bin& buO { 

// ... Zusatzlich notwendige Methode zum 
// Ablegen des Objektzustandes in einen Puffer, 
return buf; 



30 



35 



40 



45 



(6) class OldPhoneBook { 
public: 

OldPhoneBook(Bin buf) { 



Zur Erzeugung eines alten Objektes aus dem empfangenen 



// Zustand. 

// ... Die restliche Schnittstelle ist mit der 

// im zu ersetzenden Softwareobjekt identisch. 



}; 



(7) PhoneBook stateTransformation(OldPhoneBook phoneBook) { 
PhoneBook newPhoneBook; 
so II ... Diese Funktion erledigt die notwendigen Transformationen 

// vom alten 'phoneBook* zum neuen 'newPhoneBook*. 
return newPhoneBook; 



55 
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} 

(8) enum Request { Enter, Remove, Give, Exchange }; 

(9) Port* phoneBookEntry; // Nachrichtenadresse fur meine Klienten 
PhoneBook* phoneBook: // Reprasentiert das Telefonbuch 

(10) void phoneBookServiceO { 

Bin state; 

(11) if (getExcInforphoneBookEntry\ Bin() < < (int)Exchange, 10000, 
state)) { 

(12) phoneBookEntry = new Port(state): 
OldPhoneBook oldPhoneBook(state); 

phoneBook = new PhoneBook(stateTransformation(oldPhoneBook)); 
} else { 

03) phoneBookEntry = new Port( "phoneBookEntry", Port:: Overtype); 

phoneBook = new PhoneBook; 

} 

(14) while(l) { 

( 1 5) Bin message; phoneBookEntry- > receive(message); 
int request; 

message > > request; 

// Extrahiert Typ der aufgerufenen Methode aus 
// empfangenen Daten. 

(16) switch(request) { 

case Enter: 

// ... keine Anderungen 
case Remove: 

// ... keine Anderungen 
case Give: 



EP 0 743 595 A2 



// ... keine 




(17) 



case Exchange: 
Bin stale; 



state < < 



phoneBookEntry- > migrate() < < phoneBook; 



// Zustand sammeln 



delete phoneBookEntry; delete phoneBook; 

// Aufraumen noch existierender Objekte 
setExclnfo(state); // Keine Ruckkehr aus dieser Funktion. 



} 



} 



(18) Thread pBS(phoneBookService); 

// Deklariert und startet den Thread des sprachgesteuerten Telefonbuchs. 



Der oben gezeigte Programmablauf ist fur den Fall vorgesehen, daG diese Sottwarekomponente eine andere 
(vbrgangerkomponente) ersetzen soli, und fur den anderen Fall, daG diese Sottwarekomponente durch eine andere 
neue Softwarekomponente (Nachfolgerkomponente) ersetzt wird. Die Sottwarekomponente, welche die erfindungs- 
gemaBen MaBnahmen enthalt, verwendet ein zusatzliches Modul "exchangenxx" (Abschnitt (2)), das zwei Methoden 
"getExclnfo" und "setExclnfo" zur Verf ugung stellt. Die Methode "getExclnfo' stelft die Zustandsinformationen der zu 
ersetzenden Komponente der neuen Komponente zur Verfugung. Demgegenuber ubergibt die Methode "setExclnfo" 
Zustandsinformationen der aktuellen Komponente an eine sie ersetzende neue Komponente. Jeder Thread ruft also 
zu Beginn seiner Abarbeitung genau einmal die Methode "getExclnfo" und beendet seine Abarbeitung mit "setExclnfo" 
(vgl. die unten aufgef uhrten Programmablauf e). 

Die Deklarationen im Abschnitt (3) werden urn zusatzliche Methodenaufrufe erweitert, die in den auf den Abschnitt 
(3) folgenden Abschnitten (4) und (5) auf gef uhrt sind. Prinzipiell werden alle internen Objekte, soweit noch nicht vor- 
handen, urn zwei weitere Methoden erweitert. Eine Methode ist erforderlich, urn den neuen Zustand des Objektes der 
Nachfolgerkomponente aus dem Zustand eines ahnlichen Objektes der Vbrgangerkomponente zu konstruieren (Ab- 
schnitt (4)) und eine weitere Methode, urn den Zustand der Vbrgangerkomponente in eine als Nachricht versendbare 
Form zu verpacken (Abschnitt (5)). Es wird der Methodenaulrut "PhoneBook (Bin but)" verwendet, der etn Objekt aus 
einem Pufferabbild konstruiert (Abschnitt (4)). Dieser Methodenaulrut wird benotigt, wenn die beschriebene Sottware- 
komponente den Zustand hres internen Objektes "phoneBook" aus dem Obertragenen Zustand vom "phoneBook" der 
Vorgangerkomponente gewinnt. Zusatzlich wird in Abschnitt (5) eine Methode aufgerufen, die das Ablegen des Ob- 
jektzustandes in einen Puffer erlaubt. Diese Methode ist erforderlich, wenn die hier beschriebene Softwarekomponente 
(Vbrgangerkomponente) den Zustand ihres internen Objektes "phoneBook" an eine Nachfolgerkomponente ubertragen 



Prinzipiell ist es zulassig, daB die internen Objekte einer Nachfolgerkomponente nicht identisch mit den internen 
Objekten der zu ersetzenden Komponente (Vorgangerkomponente) sind. In dem Ausf uhrungsbeispiel soil das fur das 
interne Objekt "phoneBook" der Fall sein. Gelost wird diese Inkompatibilitat durch die Berertstellung einer Transfer- 
funktion "stateTransformation' (Abschnitt (7)). Diese Funktion muB in der Lage sein : den alten Typ "OldPhoneBook' 
(Abschnitt (6)) des internen Objektes "phoneBook" in seine neue Representation umzuwandeln. Das erfolgt unmittel- 
bar, nachdem der Zustand der alten Objekte empfangen wurde (siehe Abschnitt (1 2)). 

Der Abschnitt (B) gibt einen vom Objekt bereitgestelHen werteren Dienst an. Dieser Dienst "exchange" ermdglicht 



mochte. 
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den Austausch der Softwarekomponente. 

Der Thread des Telefonbuchprozesses enthaft zwei zusatzliche Programmteile. Einer 1st fur die Ubemahme der 
Zustande von emer Vorgangerkomponente und der andere Teile fur die Obergabe der Zustande an eine Nachfolger- 
komponente verantwortlich. Ob eine Vorgangerkomponente existierl wird mittels der Methode "getExclnfo" (siehe un- 
ten) ermittelL Existiert eine solche, dann ubermittelt "getExclnfo" auch den Zustand der Vorgangerkomponente Dieser 
wird zur Rekonstruktion der internen Objekte "phoneBookEntry" und "phoneBook" benutzl (Abschnitt (12)) Existiert 
keme Vorgangerkomponente, dann wird die Komponente ganz normal gestartet (Abschnitt (13)) Das Erzeugen des 
neuen Dienst-Ports wirdmit den Anweisungen inden Abschnitten (12) und (1 3) realisiert. Alle noch nicht abgearbeiteten 
Nachnchten des Dienst-Ports der alien Softwarekomponente sind Bestandteil von diesem Zustand und werden uber- 
geben. Weiter wird im Abschnitt (12) der alte Zustand des Telefonbuches aus dem Puffer 'state" extrahiert und in der 
Variablen "oldPhoneBook" abgelegt. Die oben beschriebene Zustandstransferfunktion, die den Zustand eines alten 
Telefonbuches rn den Zustand eines neuen Telefonbuches abbildet. wird in Abschnitt (12) angewendet Ein solcher 
Transfer ist beisprelsweise erforderlich. wenn ein neues Feld "Postleitzahlen" hinzukommt oder dieses Feld einen 
anderen Typ erhalt (z.B. 5 anstatt 4 Zeichen). 

Der zweite neue Programmteil (Abschnitt ( 1 7)) realisiert den f Or den Austausch der Komponente gegen eine Nach- 
f olgerkomponente notwendigen Dienst "Exchange- Zuerst wird in Abschnitt (1 7) der augenblickliche Zustand der atten 
Softwarekomponente (Vorgangerkomponente) in einem Puffer "state" abgelegt. Es werden z B der Zustand ein- 
schheBUch der Nachrichten des Dienst-Ports "phoneBookEntry" in dem Puffer -state" gespeichert. Der in dem Puffer 
state" abgelegte Zustand der alien Softwarekomponente wird mittels "setExclnfo" an die neu einzusetzende Soft- 
warekomponente (Nachfolgerkomponente) gesendet. Die Methode "setExclnfo" bricht gleichzeitig die Softwarekom- 
ponente ab. 

Der Ablaut des Threads in der Softwarekomponente mit den erfindungsgema&en MaBnahmen kann ebenfalls 
durch em Zustandsdiagramm beschrieben werden, welches in der Fig. 5 gezeigt ist. A!le Zustande, die mit denen in 
der Fig. 4 identisch s.nd, weisen dieselben Bezeichnungen aut. Der Zustand RS (Block 30, receiving stale) gibt den 
Zustand nach einem Neustart der Softwarekomponente an, bei der auf die Obertragung des Zustandes der alten Kom- 
ponente gewartet wird. Erhalt die Softwarekomponente am Ende ihrer Lebensdauer dann selbst ein Austauschsignal 
wechselt s,e ,n den Zustand CS (Block 31 , collecting state). In diesem Zustand sammelt sie die Zustande ihrer internen 
Objekte. Der Zustand TS (Block 32 : transferring state) gibt die Obertragung der Zustande von der alten auf die neue 
Softwarekomponente an. Das Beenden einer alten Softwarekomponente wird durch den Zustand TE (Block 33 ter- 
minated) angegeben. 

Das Modul "exchange.hxx", welches die Methoden "getExclnfo" und "setExclnfo" definiert wird im folgenden auf- 



(1) #ifodef FLYER^EXCHANGE 
#define FLYER_EXCHANGE 



(2) #include "bin.hxx" 



(3) im getExdnfo(const char* portName, const Bin& excReqCode, im maxState. 
Bin& state); 



(4) void setExdnfo(const Bin& state); 
#endif 



In Abschnrtt (1) wird ein Symbol "FLYER_EXCHANGE" getestet und. falls es nicht definiert ist, gesetzt Das ver- 
hmdert das mehrfache Inkludieren (Einfugen) dieses Modufe. Abschnitt (2) inkludiert die Definition der Klasse "bin- 
Die Methode "getExclnfo", welche die Zustandintormationen fur die Nachfolgerkomponente liefert, wird in Abschnitt 
(3) definiert. D.e Methode besitzl die Parameter "portName", "excReqCode", "maxState-, "state" und "return" "port- 
Name" gibt den Namen des Ports an, uber den die Leistungen dieser Softwarekomponente in Anspruch genommen 
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werden. "excReqCode" ist ein Anforderungskode, der zur Einleitung des Auslauschvorganges an die alte, zu erset- 
zende Sottwarekomponente gesendet werden soil. Die maximale GroBe des erwarteten Zustandes m Byte gibt "max- 
State" an. In "state' wird der zu ubertragende Zustand des Threads abgelegt. Der Ruckkehrwert der Funktion "getEx- 
clnlo" ist gleich 0 (FALSE), falls kein Austausch stattfinden soli. d.h. falls die Komponente einfach nur neu gestartet 
werden soil. 

In Abschnitt (4) wird die Methode definiert, welche die Zustandsinformationen des alten Threads der Vbrganger- 
komponente, die in "state" abgelegt sind, an die Nachfoigerkomponente uberbringt. Die Funktion "setExclnfo" kehrt 
nicht zuruck. Der auf rufende Thread wird geloscht. 

Das Modul "exchange.cxx", dessen Programmablauf unten dargestelt ist, beinhaltel die Implementierung der in 
dem Modul "exchange, hxx" beschriebenen Schnittstelle: 



(I) ^include * exchange, hxx w // Eigene Schnittstellenbeschreibung 



^include "excstub .hxx" 



// Schnittstelle zum Austausch-Manager 'ExcStub' 



^include "port, hxx" 



// Definiert Tort* 



^include "thread. hxx" 



// Definiert 'mySelF 



(2) 



const int False = 0, True 



= !0; 



(3) 



(4) 



static ExcStub excStub; 



static S servicePortName; 



// Schnittstelle zum Austausch-Manager 
// nur fur internen Namenstransfer 
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(5) int getExc!nfo(const char* portName, const Bin& excReqCode, int maxState, 
Bin& state) { 

servicePonName = portName; // merken fur 'setExcInfo' 

(6) // Anmeldung beim Austausch-Manager: 
ExcStub::RepIyCode rc = excStub.announce(servicePonName); 
if (rc == ExcStub::OkStart) return False: 

// kein Ersetzen sondern Neustan 

(7) // Austauschaufforderung an die zu ersetzende Komponente schicken: 
Port servicePortfportName, Port:: Reference); 
servicePort.call(excReqCode, maxState, state); 

// Die Anforderung wird verschickt und der alte Zustand empfangen. 



return True; 



(8) void setExc!nfo(const Bin& state) { 
reply(state); 

excS tub . stopped(servicePortName) ; 

// Fenigmeldung an den Austauschmanager 

mySelf()->deIetes(); 



Abschnitl (1 ) enthalt Importe bzw. Deklarationen verwendeter Klassen. So stellt z.B. "excstub_.hxx" eine Schnitt- 
stelle zum Austauschmanager 11 zur Vertugung. Abschnitt (2) definiert die Konstanten Talse" und 'True" 

Abschnltt (3) deklariert ein Objekt "excStub", uber das der Austauschmanager 11 angesprochen wird. Abschnitt 
(4) deklariert ein String-Objekt, das lediglich zum Informatioostransfer (Namenstranster) zwischen "getExclnfo" und 
"setExclnfo" benutzt wird. 

Im Abschnitt (5) beginnt die Implementation der Methode "getExclnfo". Im Abschnitt (6) meldet sich die Sottware- 
komponente beim Austauschmanager 11 an und erfahrt, ob sie neu gestartet wird oder ob sre eine existierende Kom- 
ponente (Vorgangerkomponente) ersetzen soil. 

Soil eine Vorgangerkomponente ersetzt werden, so wird im Abschnitt (7) ein Referenz-Port geschaffen, der den 
Dienst-Port der zu ersetzenden Komponente referenziert. Der Nforgangerkomponente wird nun ein Austauschbefehl 
mittels 'servicePort.cair gesendet. Sie schickt daraufhin ihren Zustand zuruck, der in 'state' abgespeichert und als 
Parameter "state* von "getExclnfo* Obergeben wird. 

Abschnitt (8) enthalt die Implementierung von "setExclnfo". Dabei wird zuerst der eingesammelte Zustand "state" 
an den Sender des Austauschbefehte zuruckgeschickt ("reply(state)"). Dann wird der Austauschmanager 1 1 informiert, 
daB die Sottwarekomponente (Vorgangerkomponente) gestoppt hat ("excStub stopped(servicePortName)") und die 
Softwarekomponente loscht sich selbst 
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Patent an sprue he 

1. Kommunikatbnssystem mit einer Steuerschaltung (3. 9), welche ein Betriebssystem (4) und Anwendersoftware 
(5) und Mittel (11 ) zum Austausch von Software enthalt, 

dadurch qekennzeichnet, 

daB das Betriebssystem (4) zum Austausch von Nachrichten vorgesehen ist und daB eine neue geladene Soft- 
warekomponente (Nachfolgerkomponente) zum Empfang der Zustande und der Nachrichten von einem Dienst- 
Port einer angehaftenen, zu ersetzenden Softwarekomponente (Vorgangerkomponente) und zum Neustart mit 
den ubertragenen Zustanden und Nachrichten vorgesehen ist 

2. Kommunikatbnssystem nach Anspruch 1 , 
dadurch qekennzeichnet, 

daB eine austauschbare Softwarekomponente einen Thread enthatl und daB der Thread einen ersten Teil zur 
Obernahme und geeigneten Umsetzung der Zustande und Nachrichten des Dienst-Ports einer alten Software- 
komponente und einen zweiten Teil zum Einsammeln der Zustande des Prozesses und der Nachrichten des Dienst- 
Ports enthalt. 

3. Kommunikatbnssystem nach Anspruch 1 Oder 2, 
dadurch oekennzeichnet, 

daB ein Austauschmanager (11) zum Laden und Starten einer Softwarekomponente vorgesehen ist. 

4. Kommunikatbnssystem nach Anspruch 1 , 2 Oder 3, 
dadurch oekennzeichnet, 

daB eine Wartungsvorrichtung (2, 10) zur Lieferung einer neuen Softwarekomponente uber ein Ubertragungsme- 
dium an den Austauschmanager (11) vorgesehen ist. 

5. Kommunikatbnssystem nach einem der vorhergehenden Anspruche, 
dadurch qekennzeichnet, 

daB bei einer veranderten Struktur der Nachfolgerkomponente zur Vorgangerkomponente die Nachfolgerkompo- 
nente zur Durchfuhrung einer Zuslandst information vorgesehen ist. 

6. Computersystem mit wenigstens einem Computer (1 ), welcher ein Betriebssystem (4) und Anwendersoftware (5) 
und Mittel (11 ) zum Austausch von Software enthalt, 

dadurch oekennzeichnet. 

daB das Betriebssystem zum Austausch von Nachrichten vorgesehen ist und daB eine neue geladene Software- 
komponente (Nachfolgerkomponente) zum Empfang der Zustande und der Nachrichten von einem Dienst-Port 
einer angehaftenen, zu ersetzenden Softwarekomponente (Vorgangerkomponente) und zum Neustart mit den 
ubertragenen Zustanden und Nachrichten vorgesehen ist. 
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FIG. 3 
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(54) Kommunikationssystem mit Mitteln zum Austausch von Software 



(57) Die Erfindung bezieht sich auf ein Kommunika- 
tionssystem mit einer Steuerschattung (3, 9), welche ein 
zum Austausch von Nachrichten vorgesehenes Be- 
triebssystem (4) und Anwendersoftware (5) und Mittel 
(11) zum Austausch von Software enthalt. Damit eine 
Softwarekomponente innerhalb weniger Millisekunden 



ausgetauscht werden karm, empfangt eine neu gelade- 
ne Softwarekomponente (Nachfolgerkomponente) Zu- 
stande und Nachrichten von ehnem Dienst-Port einer 
angehaltenen, zu ersetzenden Softwarekomponente 
(Vorgangerkomponente) . Die Nachfolgerkomponente 
wird mit den ubertragenen Zustanden und Nachrichten 
neu gestartet 
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